1. Field of the Invention
The subject invention relates to an improved method of tracing the program paths used in execution of a computer program. In addition, the subject invention includes an embedded tracing program operating according to the tracing method and a method of installing such self-tracing capability into a program.
2. Description of the Related Art
Knowledge of the paths used in execution of a program in a computer system is helpful in both designing the program and diagnosing errors that occur once the program is in the field. A program for which knowledge of the paths used in execution is of interest is herein referred to as a "target" program. One method of acquiring such knowledge is herein referred to as a "predictive" method. Predictive methods include means, such as separate programs, which analyze all of the possible paths of execution of a target program. An example of such a predictive method is disclosed in an article by K. Soule, IBM Technical Disclosure Bulletin, Vol. 14, No. 4, September 1971, pp. 1016-1019. Predictive methods can be quite helpful during the development of the program because they permit a programmer to simulate different possible environments of a target program during its expected use. Although predictive methods are time consuming because of the need to analyze all possible paths of execution of a target program, they are adequate for program development because the knowledge gained therefrom is large. Once a program is in the field, however, predictive methods are inefficient for analyzing program errors or failures. Once a program error has occurred, there is no benefit from predicting all possible paths of execution of that program. Of interest is the exact path of execution which lead to the error, so that it may be corrected. This need for efficiency is magnified by customers' need to have their program maintained in working condition. Thus, efficiency often requires the ability to determine the paths used in execution of a target program which lead to an error, rather than the ability to use predictive methods to foresee possible future errors.
Determining the paths used in execution of a target program is known as "tracing" the program. The tracing of program execution may be accomplished using either hardware or software. Tracing using hardware is accomplished by physically wiring a storage device into the logical circuits of the computer system being controlled by the target program to determine their use or nonuse. Hardware tracing methods are disclosed in articles by D. G. East, et al, IBM Technical Disclosure Bulletin, Vol. 15, No. 4, September 1972, pp. 1377-1378 and C. P. Geer, et al, IBM Technical Disclosure Bulletin, Vol. 26, No. 11, April 1984, pp. 6217-6220. The primary problem with hardware tracing methods is in properly connecting the storage device to the logical circuits controlled by the target program. In increasingly complex modern computer systems, the circuitry of which varies significantly between computer systems, it is nearly impossible to make the connection of the storage device a simple task.
Software tracing methods exist in many forms, often including parent or child programs which operate in conjunction with a target program. A parent program actually directs the execution of the target program, monitoring it as execution proceeds. A child program is called by the target program whenever certain trace points in the target program are referenced during execution. By "referenced" it is meant that a particular trace point is reached in one of the possible paths of execution. Tracing methods using parent or child programs are inefficient because the parent or child program interrupts the execution of the target program, thereby significantly increasing execution time. Thus, programs having means for tracing program execution embedded therein are preferable.
Tracing methods may also be classified according to the type of information recorded. One type of tracing method employs a "snapshot" of the computer system taken at regular intervals. Snapshots indicate the status of a computer system at the exact time they are taken or since the preceding interval. For example, the transient referencing of a trace point in the middle of an interval would be detected by a snapshot indicating the status since the last interval because the trace point was in fact referenced during the interval. However, the transient referencing would not be detected by a snapshot indicating the status at the exact time it is taken because the trace point would not be referenced at that time. Snapshot tracing methods are inefficient because the status of each trace point is recorded several times during execution of the target program, thereby significantly increasing execution time.
Other tracing methods are known, all suffering from one or more disadvantages. Some tracing methods include the recording of every program instruction, thereby drastically degrading system and program performance. Similar tracing methods attempt to overcome this problem by including the recording of only the most recently executed instructions. This method improves system and program performance compared to the aforementioned tracing method, but is still inefficient in that it does not focus on recording the paths used in execution of the target program. The method records all instructions of recent vintage, not just those indicating the direction taken at program branch points. A branch point is any location in the program from which two or more immediate paths of execution exist. For example, Bauer, et al (IBM Technical Disclosure Bulletin, Vol. 21, No. 12, May 1979, pp. 4783-4785) discloses merely tracing recent multiple level interrupts.
Other tracing methods reduce the degradation of system and program performance by including the recording of certain major events only. For example, Morse, et al (IBM Technical Disclosure Bulletin, Vol. 14, No. 3, August 1971, pp. 855-856) discloses merely tracing such major events as I/O operations. Limiting the trace to major events does improve such performance over certain earlier tracing methods, but is again inefficient in that it does not focus on recording the path of execution of the target program. For example, Morse, et al record significant amounts of performance oriented data not actually required for tracing the paths used in execution of the target program. Recording this excess information significantly increases execution time. A similar tracing method disclosed by Ruzicka (IBM Technical Disclosure Bulletin, Vol. 12, No. 6, November 1969, pp. 771-772) degrades performance by including the recording of separate records for each trace point.
Still other tracing methods include the recording of sequential tracing information. Sequential tracing methods record the order in which trace points were referenced during program execution, not merely which trace points were referenced regardless of time. For example, Harward (IBM Technical Disclosure Bulletin, Vol. 13, No. 4, September 1970, pp. 855-857) discloses a tracing method including recording the referencing of trace points located at branch points of the target program. Sequential tracing information is obtained by recording a different symbol at each trace point. The sequence of symbols recorded thus represents the sequence in which the trace points were referenced. However, performance is again degraded by the time and memory space required to generate and record a different symbol at each trace point.
Efficiency considerations require that tracing methods operate continuously during target program execution in the field. Without such continuous operation, the analysis of an error occurring during a non-tracing period would require re-execution of the target program. In addition, differences between program execution with and without tracing, such as those caused by timing considerations, could mask the analysis of certain errors by tracing or expose otherwise dormant errors.